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Alerting  m uataoase  systems:  Concepts  ano  lecnniques 
o.  teter  ouneman  ana  dowara  Lee  Morgan 

1 . ti  I w 1‘ ddOUCT low 

*ve  usually  regaru  aataoases  anu  otner  intormation  systems  as  passive 
in  tnat  tney  "speaK  only  wnen  spoxen  to.”  in  tne  real  world  nowever. 
intormation  is  otten  spontaneousl y otrereu  to  us  oy  trienas  anu 
colleagues  wno.  oeinq  aware  or  our  interests,  araw  our  attention  to 
cnanges  tnat  may  artect  us.  In  a similar  vein,  tnis  paper  uiscusses 
tne  subject  ot  "alerters",  wnicn  can  oe  used  in  a dataoase  management 
system  to  provide  tne  same  capaoiiity  ot  lnlormmg  a user  wnen  a 
specitiea  state  ot  tne  world  (as  reieiectea  in  tne  database)  is 
reacneo.  we  reel  tnat  tne  ability  to  develop  and  implement  alerters 
etticientiy  snouid  prove  a powertul  adjunct  to  modern  dataoase 
tecnnology.  Tnis  paper  describes  our  recent  researcn  in  adding 
alerting  teatures  to  uataoase  management  systems  (Jui'ia)  anu  provides  a 
trameworx  witnin  wnicn  tnis  ano  similar  researcn  ettorts  can  oe 
evaluated. 

some  simple  examples  may  net?  to  clarity  tne  concept.  Consider 
tne  commands: 

1.  "Keoort  tne  name  ot  any  station  at  wnicn  tne  temperature 
tails  oeiow  lw  degrees  Centigrade." 


l.  "deport  tne  number  ana  owner  ot  any  account  Ltom  wnicn  more 
tnan  is  witnurawn." 
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Sucn  commands  make  most  sense  in  tne  case  ot  large  snared  databases, 
in  whicn  many  users  are  entering  updates  at  tne  same  time  tnat  still 
otner  users  may  oe  querying  tne  dataoase.  Katner  tnan  require  a user 
repeatedly  to  enter  a query  ot  interest  (e.g..  1 or  2 aoove) . we 
propose  tnat  alerters  De  used.  Tnis  cnanges  tne  cnaracter  ot  the  DBMS 
rrom  a passive  one.  wnere  tne  OBrnS  only  responds  to  queries,  to  an 
active  one.  in  whicn  the  system  may  at  any  time  send  a message  to 
alert  tne  user  to  some  condition  ot  interest. 

Betore  delving  into  our  current  work.  it  is  instructive  to 
discuss  tne  existing  and  historical  technologies  tor  acnieving 
alerting  type  ettects. 


2.0  DXiaTIdd  'f tiCiiwiijdfiS 

To  our  knowledge.  there  is  no  system  which  permits  tne 
construction  ot  alerters  in  tne  sense  in  wnicn  we  have  descnoeo  them: 
as  general  user-oetineo  programs  wnich  monitor  online  oataoases. 
however,  some  of  tne  ingredients  are  available  in  various  programming 
language  and  database  management  systems,  and  it  is  wortn  examining 
tnem. 

1.  exception  Reporting. 

several  tile  management  systems  permit  tne  construction  ot 
programs  wnicn  take  some  action,  usually  issuing  a report, 
and  wnicn  are  activated  wnenever  a recoro  is  read  in  during  a 
sequential  pass  ot  tne  file.  tor  example.  Ktuilij  ano 
versions  ot  CobolIIJ  nave  a ubb  statement.  inis  permits  a 
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more  or  less  non-procedural  metnou  ol  constructing  tile 
management  programs.  ASAP 1 2 J allows  a program  segment  to  Oe 
treatea  as  a "tag",  wnicn  is  stored  witn  tne  dataoase.  Tnese 
tags  are  tnen  run  wnenever  any  user  upaates  tne  aataoase. 
rne  tags  can  use  a CHAwSS  lunction  to  test  tor  wnetner  a 
tielo  nas  oeea  updated.  An  example  would  oe: 

OPFIwB  TAP  WA  I'Cii ACCOUNT 

top  APL  ACCOUNTS  wil'd  CdANUL  UP  SALAWCS= ' i PS 1 Awl)  dALAwCS  <k) 
PHI NT  HSPUKT  NSwwSGuALAnCS 

Tne  aoove  are  really  designed  tor  oaten  processing 
systems.  To  use  tnem  as  a means  or  implementing  alerters 
would  require  trequent.  metticient  scans  or  tne  uataoase. 
moreover,  nowever  simple  it  is  to  write  tnese  programs,  tney 
are  usually  tne  province  ot  tne  applications  programmer, 
ratner  tnan  tne  end  user. 

Prror  dandling  is  anotner  special  case  ot  exception 
reporting.  Hammer loj  nas  recently  discussed  tne  use  ot 
alerting  type  teatures  tor  preventing  semantic  errors  rrom 
creeping  into  uataoases. 

2.  pL/1 

a usetui  feature  ot  tne  PL/I  language  is  tne  "ON"  condition, 
wnicn  permits  tne  programmer  to  process  interrupts.  Togetner 
witn  PIoNAL.  wnicn  lets  tne  programmer  generate  interrupts,  a 
metnou  tor  as /nenronous  processing  is  availaole. 
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Common  uses  tor  tne  oil  conuition  are  tor  ueougging.  e.g. 
tor  reporting  wnen  the  value  ot  a variaole  exceeos  some 
pound.  for  tne  trapping  ot  end  ot  tile  and  similar  I/u 
conditions,  and  for  handling  machine  faults  (e.g.  arithmetic 
overflow,  division  by  zero) . 

Zel Xowi tz l 1 4 J and  AorganloJ  nave  implemented  versions  ot 
an  extended  PL/1  (botn  Dased  on  tne  PL/C  compiler  l Ik)  J ) wnicn 
permit  general  conditions  ot  tne  torm: 
ow  X+7>l-d  00; POT  LIST  X.YjSWO; 


Tnese  implementations  pose  an  interesting  version  ot  the 
oinuing  proolein  in  olocx  structured  languages.  In  the  aoove 
conditional,  is  tne  value  ot  ! to  oe  taken  as  tne  value  it 
nas  at  the  time  tne  condition  is  uetineo.  or  is  it  to  oe 
taken  as  tne  value  it  nas  at  tne  time  it  is  invoked.'1  In 
accordance  witn  r'ne  /mouL  conventions,  tne  tor.uer  is  cnosen. 
uowever.  tnere  are  situations  where  the  latter  cnoice  may 
appear  more  natural.  »«e  snail  siue-step  tnis  issue  oy 
insisting  that  alerters  attacn  to  referents,  ratner  tnan  to 
tne  names  tnemselves. 


J.  eLAwrt&K  ana  CoiMhlPSK 

sotn  triese  languages l lzj  allow  tne  programmer  to  set  up 

antecedent  theorems.  otten  called  "demons",  wnicn  are 

programs  that  monitor  additions  ana  deletions  to  tne 

"dataoase”  (an  incore  set  ot  lists),  ana  require  certain 

actions  to  oe  taken  oetore  tne  addition  or  deletion  can 

- ----  quite  close  to  wnat  we  are 


occur 


In  principle,  tnis 
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proposing,  out  it  is  quite  aitterent  in  uetaii  ana  intent. 

in  particular,  we  snail  not  let  an  alerter  interrere 
witn  an  upaate  in  the  sense  in  wnicn  an  anteceaent  theorem 
can.  In  etrect.  mucin  ot  wnat  we  propose  (ana  nave 
impiementea)  is  meant  to  maxe  uemons  practicaole  ana 
etficient  tor  a modern  aataoase  system  (i.e..  a large, 
structured.  snared  dataoase  requiring  tne  use  ot  secondary 
storage) . 

4.  system  R 

one  ot  the  proposed  teatures  ot  System  RtllJ  is  tne  TRIPPER 
command.  Tms  would  permit  one  to  put  semantic  integrity 
constraits  ot  the  type  Hammer  nas  discussed  into  a DcMS.  As 
tar  as  tne  authors  could  determine,  tnis  nas  not  oeen 
implemented,  and  it  is  not  expected  to  oe  in  tne  early 
versions  ot  tnis  experimental  system. 


j.b  OEr'INlTiON  dr’  AuER'i'ER 

i<lorganl7J  nas  presented  a detailed  detmition  ot  an  Event 
bequenced  program.  nuca  ot  tnis  worx  dealt  witn  resolving  conilicts 
among  programs  wnicn  simultaneously  attempt  to  update  tne  same 
vartaole.  due  to  simultaneously  triggered  alerts.  in  ms  system  l <>J, 
tne  operation  ot  tnese  programs  was  conceptually  synchronous  ana.  HKe 
antecedent  theorems.  preceded  tne  update.  tor  reasons  wnicn  snail 
appear  shortly,  we  now  believe  tnat  it  is  oest  tnat  alerters  operate 


■ mmmmmMmm* 
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asyncnronously . Also,  we  propose  a different  metnoa  ot  coping  witn 
tne  contiicts. 

»Me  simply  aetine  an  alerter  as  a conuition.  program  pair.  To 
start  witn.  we  may  consider  tne  conuition  to  oe  any  predicate  on  the 
state  ot  tne  dataoase.  and  tne  program  to  oe  any  general  program, 
unior tunately . this  is  noth  unworxaoie  ano  inadequate:  oy  making  tne 
condition  "true."  we  can  specity  that  tne  program  run  continuously, 
nvnile  this  may  oe  a pleasing  tneoretical  contruct.  it  is  practically 
aonorrent.  Tne  definition  is  inadequate  in  tne  sense  that  we  may  wish 
to  include  in  tne  predicate  items  wnicn  are  not  in  tne  dataoase.  e.g.. 
tne  current  time  ot  day.  Moreover,  we  are  usually  more  interested  in 
monitoring  cnanges  to  a dataoase  tnan  its  instantaneous  state. 

Tne  two  examples  in  tne  introduction  snow  tnis.  In  tne  tirst 
case  tne  request  is  tnat  some  response  is  triggered  at  the  moment 
"temperature  is  less  tnan  degrees  Centigrade"  becomes  true.  in  tne 
second,  we  are  asxing  that  tne  magnitude  of  Change  ot  some  value  oe 
monitored.  In  constructing  tne  condition  part  ot  tne  alerter  it  must 
oe  possible  to  teter  to  the  state  ot  tne  uataoase  ootn  oeiore  anu 
alter  tne  proposed  cnange  wnicn  tnat  condition  is  monitoring.  it  may 
also  oe  nelptul  to  nave  inrormation  aoout  ooth  states  or  tne  uataoase 
passed  through  to  tne  program  that  is  activated  Oy  tne 
condition. 


The  complexity  ot  tne 
determinant  to  tne  utility  ot 
spcitcation  of  tne  underlying 
tnree  levels  ot  alerting  cond 


alerter  predicates  is 

alerting,  ano  is  directly 

database  model.  *ve  nave 
itions.  described  oeiow. 


tne  crucial 
related  to  tne 
distinguished 
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d.l  simple  Alerting 

Alerts  wmcn  can  oe  monitorea  oy  dealing  witn  only  a single 
record  class  (or  a single  relation  in  a relational  aataoasej  are 
relatively  simple  to  iianaie.  Tne  tallowing  predicates  are 
representative  ot  simple  alerting. 

1.  item.  monitor  one  or  more  fields  ot  a given  record,  e.g.. 
temperature  in  wew  iork. 

/.  record.  monitor  a given  record,  e.g.,  any  cnange  to  tne  Pew 
i ock  City  recoru. 

i.  monitor  one  or  more  fields  in  an  aroitrary  record  in  a class, 
e.g..  monitor  tne  temperature  at  any  station. 

4.  Addition  ot  record  to  a class,  e.g..  monitor  new  stations 
added . 

o.  deletion  ot  a record  from  a class. 

o.  Any  field  in  any  record,  e.g.  tell  me  iL  anyone  cnanges 
anytning  in  tne  weatner  station  records. 


we  snould  note  tnat  one  can  suostitute  "tuple"  tor  recoru, 
"relation"  tor  record  class,  and  "domain"  tor  Held  in  tne  aoove 
discussion,  wituout  loss  ot  meaning.  ,\e  also  note  tnat  tne  primary 
Keys  are  usually  not  permitted  to  cnange.  wnat  tor  example,  would  it 
mean  it  a user  requested  an  alert  on  tne  temperature  in  new  tot*.  City. 


ana  tne  Key  W^ew  ¥orK  City"  were  changed/ 
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I. 2  Structural  Alerting. 

Tnese  alerter  preuicates  inuicate  cnanges  in  tne  dynamic 
structure  ot  tne  uatauase.  Tney  will  oe  explained  in  terms  oi  uB'i’d 
terminology . altnougn  tney  are  equally  valid  tor  relational  dataoases, 
proviaea  we  regard  relations  as  aynamic  objects. 

1.  Cnange  in  ownersnip  or  memoer snip  ot  sets.  E.g.  a doctor 
acquires  a new  patient. 

2.  Cnange  in  aggregate  properties  ot  sets.  E.g..  a doctor  gets 
more  tnan  2k)  new  patients. 

j.  Cnange  in  tieids  with  uitterent  record  classes.  h.g..  a 
doctor  gets  a patient  with  cnicKen  pox  (either  oy  tne  doctor 
acquiring  the  patient,  or  an  existing  patient  acquiring 
cnicken  pox ) . 

Tnese  alerters  are  more  complicated  to  implement  since  tney  may 
involve  interactions  oetween  more  tnan  one  record  class. 

J. J  Complex  Alerting 

we  include  nere  predicates  wnicn  we  would  iiKe  to  oe  aole  to 
nanuie.  Dut  wnicn  require  still  more  glooal  views  ot  the  database 
system  and  its  user  interactions. 
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1.  statistical 

aler 

ters. 

6 . g . . let  me 

know  wnen 

tne 

average 

temperature 

m 

tne 

wortneast  drops 

oy 

more  than  ltd 

degrees , 

Clearly,  one 

can 

come 

up  witn  etticie 

nt 

methods 

tor 

nanulmg 

simple  statistical  tunctions  (with  averages  oy  maintaining  a 
special  counter  wnich  is  upuateu  appropriately),  out  tne  more 
uilticult  the  tunction.  the  less  likely  tnat  sucn  a routine 
exists,  and  tne  more  lixely  tnat  a scan  ot  tne  uataoase  may 
oe  required. 

2,  transaction  spanning  alerters.  fci.g..  let  me  Know  wnen  a oanx 
oalance  drops  oy  more  tnan  lu.tiuu  in  any  24  nour  perioo. 
inis  requires  a constant  rolling  history  lor  24  nours. 

i.  pattern  recognition.  Monitoring  lor  tne  occurence  ot 
specilic  patterns  in  tne  uataoase.  This  is  closest  to 
CONUiytK' s original  intentions  lor  using  uemons.  Again, 
eiticient  implementation  requires  a lot  ot  proDiem  specitic 
Knowledge . 

4.  time  oaseu  alerting.  i'ms  is  similar  to  tranasction 
spanning.  in  tnat  one  otten  uoes  not  require  instant 
alerting.  Dut  ratner  alerting  tnat  doesn't  come  too  late, 
for  example,  one  may  wisn  to  oe  informed  witmn  one  weex  it  a 


oarticuiar  cnecx  is  casneu. 
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1c  is  usual  ioc  a uata  managment  system  to  provide  tne  programmer 
witn  a set  or  suoroutines  wnicn  tocm  tne  intertace  oetween  ins  program 
ana  secondary  storage.  because  snaraointy  ot  uataoases  xs  central  to 
our  conceot  ot  alerting,  we  need  to  view  tne  data  managment  system  in 
a airterent  way.  Tne  uataoase  itseit  consists  ot  a separately  running 
300  wnicn  serves  many  users  ana  communicates  witn  tnem  oy  sending  an u 
receiving  messages,  oimilarly.  any  user  wisning  to  interrogate,  or  to 
mouiry.  tne  aataoase,  aoes  so  Dy  sending  it  tne  appropriate  message. 

Tne  distinction  oetween  message  passing  ana  suoroutine  calling 
may  seem  unnecesary.  especially  since  messages  will  certainly  oe 
rormatted  ana  sent  oy  spec ial-pur pose  suoroutines.  riowever . tne 
distinction  is  important  at  two  levels.  Tne  programmer  must  oe  aware 
tnat  communication  witn  tne  aataoase  is  not  instantaneous  and  tnat.  as 
tar  as  possioie.  nis  programs  should  oe  aesignea  to  worn 
asyncnronously . At  a conceptual  level.  tne  environment  in  wnicn 
messages  are  processed  is  suogect  to  external  mtluences;  wnereas 
suoroutines  are  usually  tnougnt  to  operate  in  a more  preoictaole 
environment,  anu  to  nave  a degree  ot  control  over  tne  aata  wnicn  is 
consiaeraoly  greater  than  in  a message  passing  system.  It  is 
precisely  because  tne  environment  is  suoject  to  unpredictable  cnanges 
tnat  alerting  is  a usetul  concept.  in  addition.  tne  sottware  to 
nanole  message  passing  in  computec  networxs  is  simpler  tnan  tnat 
required  to  set  up  a virtual  (synenronous)  cnannei.  pence.  tnis 
aoproacn  may  nave  advantages  in  a uistnouteu  processing  system. 
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as  an  example.  tno  oul>mn  system  wnicii  we  snail  snortiy  uesctioe. 
incorporates  a miniature  operating  system.  Tms  is  capaoie  or 
servicing  several  users  m audition  to  tne  oataoase  manager  wno  nas 
privileged  control  over  tne  system.  r'or  eacn  user,  a two-way 
communication  system  is  set  up  in  wmcn  messages  are  gueueu  in 
snaraole  riles.  one  sucti  user  is  a decision  aiding  system  Known  as 
l/A1o  i ( ^ J wnicii  maxes  neavy  use  ot  alerting.  Any  transaction  witn  tne 
oataoase  — queries,  updates  ana  setting  alerts  — is  passed  to  LobmOn 
tnrougii  tnese  tiles.  uAioi  also  periodically  reaus  its  mail  trom 
aubi’UU  wnicn  may  contain  tne  response  to  a query,  an  alert  message,  or 
an  error  message  indicating  tnat  a previous  communication  trom  oAIai 
was  incomprenensioie . In  tne  second  or  two  oetween  sending  a message 
to  Lutii'iON  anu  receiving  tne  answer,  a DAioi  user  can,  ano  usually 
does,  continue  to  worx  on  some  otner  aspect  ol  ms  uecision  maxing, 
in  snort,  neitner  system  is  in  control;  neitner  can.  in  normal 
ooeration.  disrupt  tne  otner;  out  LUtmiow  at  least  is  ooligeo  oy 
contract  to  answer  messages  sent  to  it. 

we  expect  tnat  witn  tne  growtn  ot  computer  networxs  ano 
aistnouteo  oataoases.  tms  message  passing  pniiosopny  will  oeco.ue 
iiiore  prevalent.  r’o  use  it  properly  will  call  tor  tne  Lurtner 
development  or  nign  level  languages  tor  communicating  witn  uataoases. 
in  order  to  scan  a tile  sequentially  Lor  a record  witn  given 
properties,  it  is  impr ac t icaole  to  send  ano  receive  a message  tor  eacn 
record.  Katner.  tne  specitications  tor  tats  searcn  snoulo  oe 
transmitted  as  one  message,  and  tne  message  (as  alreauy  Happens  in 
LuPnow)  snoulo  tnen  Pe  expanded  py  tne  oataoase  into  tne  appropriate 


program 
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a.y  i'tib  Lutii'iuw  p^stoi 

over  tne  past  year,  the  authors,  together  with  stan  Cooen.  nave 
implemented  a system  which  supports  simple  alerting  ana  tne  tyoe  ot 
message  passing  tacilities  just  ciescrioea.  LDtirlON  is  written  in  Lise 
anu  will  accept  such  messages  as: 

ALdk'1'  "rrost  warning"  (STATION) 
lfJus'i  TbmebKATUKb 

inCN  jlNJ  ("rrost  warning  lor  " , namL) 

me  Lunction  ot  tms  alerter  snouici  oe  odviuus  once  it  is  understood 
tnat  STATION  reters  to  a class  ot  records  ana  that  TcXi't.KAi'tJKfc.  ana 
rtrtmt-  are  neias  ot  that  class. 

me  oasis  ot  LDfcmloN  is  a set  ot  programs  tor  constructing  anu 
mam  auiating  records.  Record  classes  may  oe  dynamically  uetinea.  ana 
tne  Lise  tunctions  tor  accessing  their  lielus  are  automatically 
constructed.  in  addition.  procedures  are  provided  ror  aauing. 
deleting  anu  moditying  records.  Tms  system  is  consistent  with  a 
relational  mouei  anu  a (not  especially  etncient)  set  ot  programs  nave 
oeen  adueu  to  the  system  wmcn  provide  tor  tne  usual  relational 
constructs . 

LDfci'iON  allows  a special  class  ot  programs,  called  demons.  These 
may  contain  conditionals  ot  tne  torm  it'jusr  <conution>  rutN  <actions>; 
.■leaning  tnat  <actions>  are  to  oe  pertormeu  whenever  <conaition>  has 
]ust  oecome  true.  Changes  wmcn  cause  a particular  state  ot  tne 

oataoase  to  occur  can  tneretore  oe  monitored.  utten.  it  is  more 
uesiraoie  to  monitor  tor  some  property  ot  tne  change  itseit.  rather 
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tnan  tot  tne  resulting  state  ot  tiie  aataoase.  A ae.non's  conation  may 
also  contain  reterences  to  tne  state  ol  tne  aataoase  wmcn  just 
preceaea  a cnange.  inus. 

lb'  (OLl)  oAliAwCfci  - PALAdCu)  > oWid  TatiiM  . . 
can  oe  usea  to  monitor  withdrawals  trom  an  account.  Tnese  conditions 
may  oe  predicates  in  a comoination  ot  tieids  trom  some  record  class 
ana  may  oe  used  to  eitect  all  torms  ot  simple  alerting  uescnoea 
aoove.  in  particular. 

lb'JuST  (PALaNvJo  < iUU)  AnO  (ACCOUNT#  = 1^34)  I’HtiN  . . . 

nas  tne  ettect  ot  monitoring  a given  tieid  ot  a given  record. 

Tne  distinction  oetween  alerters  ana  demons  lies  in  wnat  Kinus  ot 
action  tney  are  alioweu  to  taKe.  tor  a uemon.  tne  action  part  may  oe 
anything  including  a program  wmcn  may  itselt  mouity  tne  aataoase. 
tor  reasons  given  oelow.  this  is  unacceptable.  moreover,  with  an 
incorrect  program,  a demon  may  "nang"  tne  aataoase  lnaenniteiy . xne 
action  ot  an  alerter  is  limited  to  sending  messages  in  various 
lormats.  bet  us  make  clear  again  tnat  a user  senus  messages  to  ootmlon 
wmcn  operates  as  a separate  ]op.  In  audition  to  alerters,  a user  .nay 
senu  messages  to  LPta'idN  wmcn  interrogate  or  mouity  tne  uataoase.  AIL 
tnese  messages  are  translated  into  suitaoie  uob  programs:  in 

particular,  an  alerter  message  is  cnecKeu  oy  L.ut>iUw  Luc  consistency 
witn  tne  uataoase  anu  is  tnen  translated  into  a demon  wmcn  is  aoueo 
to  tne  system.  ims  means  tnat  we  can  no  longer  Look  upon  tne  wnoie 
orocess  as  oeing  synchronous:  alerter  messages  are  ellectiveiy  issueu 

alter  tne  uouate  nas  taiten  place.  most  im  oor  tantiy , we  cannot  use  an 


alerter  in  outmiuA  lot  preventing  an  update. 


■ I - 
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rne  tact  that  outirtud  is  limited  to  sending  anu  receiving  messages 
in  restricted  tocmats  does  not  mean  tnat  tnese  messages  are  just 
displayed  at  the  user's  terminal.  from  a suitaole  version  ot  the 
OAloi  system  mentioned  aoove.  it  is  possioie  to  send  Lutmiow  a message 
sucn  as 

ALhKT  "overdrawn"  (ACCOUNT) 

1 F J uoT  dALAwCci  < U 'i'.icid 

Kuw  accountcneck (ACCOUNT* ) 

two 

Trie  program  "accountcnecK”  resides  in  the  OAIP*  system  anu  not  in 
uUtSrtod;  and  tne  instruction  kUn  is  interpreted  oy  LbbriuM  as  an 

intruction  to  send  oack  a message  in  a focm  whicn  will  cause  tne 
execution  ot  tins  program  witn  tne  appropriate  arguments. 

one  ot  tne  most  important  aspects  ot  alerting  is  etticiency. 
LueriOri  operates  oy  monitoring  transactions  witn  tne  oataoase  ratner 
tnan  oy  any  torm  or  searcn.  l'nis  means  tnat  tne  overneau  tor  Keeping 
an  alerter  in  tne  system  depends  on  tne  ttequency  or  transactions  witn 
tne  oataoase  out  is  independent  ot  its  size.  Tne  following  is  an 
mrormal  description  ot  wnat  Happens  in  LUCi'idiM  wnen  an  alerter  is 
added  to  tne  system  anu  suoseguently  activated. 


•j.l  Adding  An  Alerter  To  Tne  oystem 

1.  on  receiving  an  alerter  message.  tne  alerter  is  "stamped" 
witn  tne  identification  ot  tne  user  w no  sent  it.  it  is  t nen 
cneckea  tor  consistency  with  tne  oataoase  "scnema".  i’nat  is. 


Lieiu  names  must  oe  Known  to  tne  system,  and  related  to  tne 
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proper  recoru  types.  nny  inconsistency  causes  an  error 
message  to  oe  returned. 

Toe  action  portion  is  decooeu.  and  user  specitic  commands 
(sucn  as  ociwu)  are  cnecKed.  At  tms  time,  in  tne  L,lPtJ  cased 
system,  a new  tunction  is  constructed  wnicii  will  actually 
seno  tne  appropriate  response  it  tne  alerter  is  triggered  and 
tne  condition  is  met. 

p.  Tne  alerter  is  injexeo  under  tne  (rieid.  record  class;  pair 
lor  ean  iield  name  wnich  appears  in  tne  condition. 

4.  At  tnis  point,  a "APfa'KT  PtT"  message  is  sent  oacx  to  tne 
sending  user. 


p.2  Triggering  An  Alerter 

1.  rtnen  a moaitying  update  is  to  be  pertormeu.  a copy  ot  tne  oio 
values  are  made  in  a temporary  area. 

2.  i’ne  upuate  is  completed  ano  a copy  ot  tne  upuateu  values  are 
also  placed  in  temporary  store. 


pitner  oy  comparing  tne  two  recorus  in  temporary  store,  or  oy 
examination  ot  tne  upuating  transaction,  a list  ot  attecteu 
(cnanged)  tielos  is  constructed. 
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Any  alerter  indexed  unaer  tne  appropriate  recoru  class  ana 
tieia  name  is  activateu;  i.e..  its  condition  is  evaluated 
witn  respect  to  tne  records  in  temporary  storage  anu.  it 
satisfied.  tne  runction  wnicn  sends  tne  appropriate  messayes 
is  mvoxeu. 


o.U  CONFLICTS 


tiucn  ot  Morgan's  worKloJ  was  dedicated  to  resolving  contlicts  among 
tiie  "event  sequenced  programs",  wnicn,  in  tne  present  terminioyy  would 
De  tne  actions,  since  alerters  cannot  mtertere  witn  updates,  anu  can 
only  nave  tne  "siue  ettect"  or  sending  a message,  tnere  is  no  coninct 
proolem  as  tar  as  tne  aataoase  system  is  concerned. 

At  a more  ylooai  level.  However,  we  may  stiii  run  into  tne 
conriict.  tor  example,  suppose  tnat  two  people  independently  receive 
an  alert  inuicatiny  tnat  an  account  is  not  properly  oaianceu.  one 
tries  to  tix  tins  witn  a credit  entry,  anu  tne  otner  witn  a aeoit. 
causing  it  to  again  go  out  ot  oaiance.  as  a result.  tney  eacn  get 
called  again  anu  . 

we  propose  tnat  in  any  snared  aataoase.  a user  sending  an  update 
nas  some  implicit  Knowledge  aoout  tne  items  oeing  updated.  It  tnat 
Knowledge  does  not  corresponu  witn  tne  values  actually  in  tne 
dataoase.  tne  update  snoulci  not  oe  permitted.  in  otner  words,  ratner 


tnan  iocKiny  and  unlocKing  tne  record  (or  pernaps  a large  numoer  ot 


recorus 


tor  complex  alerting). 


we  permit  tne  user  to  send  a 
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conditional  upoate  wnicn  is  ettective  only  it  tne  recoro  to  oe  upoateu 
is  tne  same  as  wnen  tne  user  last  inspected  it.  (similar  to  one  or 
oijxstra's  "guatueu  commands" ) . It  tne  condition  is  not  satistieu. 
tne  update  is  rejected,  and  tne  user  must  reread  tne  record. 

System  Kill]  permits  tne  users  to  uetine  transactions,  wnicn 
involve  essentially  a stream  or  commands,  all  ot  wnicn  must  oe 
executed  it  any  are  to  oe.  Tnis  is  tne  tyoe  ot  teature  wnicn  we  are 
proposing  to  use  tor  resolving  "coni  1 lets'*  ot  tnis  nature. 


/ . io  »yAwo 

in  addition  to  alerting  witnin  tne  relational  context,  as 
aescrioeo  aoove . we  nave  Deen  implementing  these  concepts  in  tne  ub'iu 
trameworx.  wAnU  (^natton  alerting  network  uataoase)  tdj  was  originally 
designed  as  a research  vehicle  ror  testing  concepts  wnicn  could  oe 
applied  to  udi'o  uataoases.  In  audition  to  tne  standard  udl'b  teatures. 
tnere  is  an  interactive  "navigation"  aiu.  and  plans  tor  a dynamic 
restructuring  capability  1 4 J . t'or  alerting,  it  will  oenave  in  tne  same 
tasnion  as  uotmiow. 

Ine  modil  ications  are  to  tne  moult'*  .nodules  ot  tne  system,  anu 
tne  STOKC  tunctions.  t<.  Cortes,  along  with  one  ot  us(oi'ti)  is 
currently  implementing  ootn  simple  anu  structural  alerting  teatures  in 


tnis  system. 
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d . d COwCLUPIdftS 

we  nave  snown  tnat  a reasonaoly  large  class  ot  alerters  (simple 
ana  structural)  can  oe  implemented.  witn  a computing  time  overneau 
wmcn  is  muepenuent  ot  tne  numoer  ot  recoros  in  a large  oataoase. 
t’ne  extra  time  required  to  nandie  alerting  along  witn  normal  aataoase 
uouating  is  uepenuent  only  on  the  numoer  and  complexity  or  tne  alerter 
conditions  tnemseives. 

an  experimental  system  witn  tnese  teatures  nas  oeen  implemented 
in  LIdiJ  ana  running  tor  over  a year.  A similar  system,  wording  witn 
u dTo  uataoases.  is  to  oe  completed  later  this  suminer.  botn  ot  tnese 
are  in  use  and  tne  concept  ot  alerting  is  oeing  tested. 

we  reel  tnat  alerting  teatures  are  a natural  extension  to 
uataoasa  tecnnoiogy.  ana  tnat  tney  should  oe  ptanneu  tor  in  any  major 
uataoase  implementations. 
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